Reviewing files that changed from the base of the PR and between e0d50b8 and 806303a.

• .env.example (1 hunks)
• .github/workflows/test.yml (0 hunks)
• todo/dto/responses/create_team_response.py (1 hunks)
• todo/dto/team_dto.py (1 hunks)
• todo/middlewares/jwt_auth.py (4 hunks)
• todo/models/team.py (1 hunks)
• todo/repositories/team_repository.py (1 hunks)
• todo/serializers/create_team_serializer.py (1 hunks)
• todo/services/team_service.py (1 hunks)
• todo/tests/integration/base_mongo_test.py (1 hunks)
• todo/tests/unit/middlewares/test_jwt_auth.py (0 hunks)
• todo/tests/unit/views/test_auth.py (8 hunks)
• todo/urls.py (1 hunks)
• todo/utils/google_jwt_utils.py (4 hunks)
• todo/views/auth.py (5 hunks)
• todo/views/team.py (1 hunks)
• todo_project/settings/base.py (2 hunks)

• .github/workflows/test.yml
• todo/tests/unit/middlewares/test_jwt_auth.py

todo/models/team.py (1)

9-23: Well-designed team model with proper field types and relationships.

The model structure is excellent with appropriate use of PyObjectId for MongoDB IDs, proper timestamp handling with UTC timezone, and comprehensive metadata fields. The soft deletion pattern with is_deleted is a good practice.

todo/urls.py (2)

5-5: Good addition of team functionality to URL routing.

The import and route addition follows Django conventions and integrates well with the existing URL patterns.

---

15-15: Properly configured team API endpoint.

The teams endpoint is correctly configured and will handle team creation requests through the TeamListView.

todo/tests/integration/base_mongo_test.py (1)

22-24: Proper test configuration for frontend URL support.

The addition of FRONTEND_URL setting supports the authentication redirect functionality and maintains consistency between test and production environments.

todo/serializers/create_team_serializer.py (1)

1-12: LGTM! The serializer implementation is solid.

The field definitions are appropriate and follow DRF conventions correctly. The validation logic covers the expected team creation requirements.

todo/dto/team_dto.py (1)

6-21: LGTM! The DTO design is well-structured.

Both DTOs appropriately model the data structures for team creation and representation. The field types and optional/required settings align well with the business requirements.

todo/utils/google_jwt_utils.py (4)

32-33: LGTM! Correct transition to asymmetric key signing.

The change from SECRET_KEY to PRIVATE_KEY is appropriate for RSA-based JWT signing with RS256 algorithm.

---

56-57: LGTM! Consistent use of PRIVATE_KEY for token generation.

The refresh token generation correctly uses the private key for signing.

---

68-69: LGTM! Correct use of PUBLIC_KEY for token validation.

The transition to using PUBLIC_KEY for token verification is appropriate for RSA-based JWT validation.

---

78-81: Enhanced error handling improves debugging capabilities.

The more granular exception handling with specific error messages will help with troubleshooting JWT issues.

todo_project/settings/base.py (1)

123-142: Excellent conditional JWT configuration design.

The approach of using different JWT algorithms and keys for testing vs production is well-implemented:

• Testing: HS256 with hardcoded keys for simplicity and speed
• Production: RS256 with environment-provided keys for security
• Flexible: Token lifetimes configurable via environment variables

This design provides good separation of concerns and maintains test isolation while ensuring production security.

todo/services/team_service.py (4)

16-27: LGTM! Proper user validation before team creation.

The validation logic correctly checks for the existence of all member IDs and POC ID before proceeding with team creation. This prevents creation of teams with invalid user references.

---

30-38: LGTM! Clean team model creation and persistence.

The team creation logic properly constructs the TeamModel with all required fields and uses the repository pattern for persistence.

---

55-64: LGTM! Proper handling of creator membership.

The logic correctly ensures the team creator is added to the team if they're not already included in the member_ids list.

---

71-82: LGTM! Clean DTO conversion and response creation.

The conversion from model to DTO and wrapping in CreateTeamResponse is properly implemented.

todo/views/team.py (3)

35-51: Refactor unconventional error handling pattern.

The current implementation wraps ApiErrorResponse inside ValueError, which is an anti-pattern. Custom exceptions should be raised directly for better code clarity and maintainability.

Consider creating a custom exception class and raising it directly:

-        except ValueError as e:
-            if isinstance(e.args[0], ApiErrorResponse):
-                error_response = e.args[0]
-                return Response(
-                    data=error_response.model_dump(mode="json"), 
-                    status=error_response.statusCode
-                )
-
-            fallback_response = ApiErrorResponse(
-                statusCode=500,
-                message=ApiErrors.UNEXPECTED_ERROR_OCCURRED,
-                errors=[{"detail": str(e) if settings.DEBUG else ApiErrors.INTERNAL_SERVER_ERROR}],
-            )
-            return Response(
-                data=fallback_response.model_dump(mode="json"), 
-                status=status.HTTP_500_INTERNAL_SERVER_ERROR
-            )
+        except ApiException as e:
+            return Response(
+                data=e.error_response.model_dump(mode="json"), 
+                status=e.error_response.statusCode
+            )
+        except Exception as e:
+            fallback_response = ApiErrorResponse(
+                statusCode=500,
+                message=ApiErrors.UNEXPECTED_ERROR_OCCURRED,
+                errors=[{"detail": str(e) if settings.DEBUG else ApiErrors.INTERNAL_SERVER_ERROR}],
+            )
+            return Response(
+                data=fallback_response.model_dump(mode="json"), 
+                status=status.HTTP_500_INTERNAL_SERVER_ERROR
+            )

You'll need to define a custom exception class:

class ApiException(Exception):
    def __init__(self, error_response: ApiErrorResponse):
        self.error_response = error_response
        super().__init__(str(error_response))

⛔ Skipped due to learnings

Learnt from: Achintya-Chatterjee
PR: Real-Dev-Squad/todo-backend#52
File: todo/views/task.py:98-112
Timestamp: 2025-06-02T17:02:22.424Z
Learning: The todo-backend project uses a global exception handler that automatically handles TaskNotFoundException, BsonInvalidId, ValueError with ApiErrorResponse, and DRFValidationError. Views should avoid try-catch blocks and let exceptions bubble up to the global handler for consistent error formatting and status codes.

Learnt from: Achintya-Chatterjee
PR: Real-Dev-Squad/todo-backend#52
File: todo/views/task.py:98-112
Timestamp: 2025-06-02T17:02:22.424Z
Learning: In the todo-backend project, there is a global exception handler in `todo/exceptions/exception_handler.py` that handles exceptions globally, eliminating the need for try-catch blocks in individual view methods. This approach reduces boilerplate code and provides consistent error handling across the application.

---

35-51: Simplify error handling pattern.

The current error handling pattern of catching ValueError and checking if it contains an ApiErrorResponse is complex. Consider using custom exceptions for better clarity.

         except ValueError as e:
-            if isinstance(e.args[0], ApiErrorResponse):
-                error_response = e.args[0]
-                return Response(
-                    data=error_response.model_dump(mode="json"), 
-                    status=error_response.statusCode
-                )
+            # Handle service-specific errors
+            if hasattr(e, 'error_response'):
+                error_response = e.error_response
+                return Response(
+                    data=error_response.model_dump(mode="json"),
+                    status=error_response.statusCode
+                )
 
             fallback_response = ApiErrorResponse(
                 statusCode=500,
                 message=ApiErrors.UNEXPECTED_ERROR_OCCURRED,
-                errors=[{"detail": str(e) if settings.DEBUG else ApiErrors.INTERNAL_SERVER_ERROR}],
+                errors=[{"detail": str(e) if settings.DEBUG else ApiErrors.INTERNAL_SERVER_ERROR}],
             )
             return Response(
-                data=fallback_response.model_dump(mode="json"), 
+                data=fallback_response.model_dump(mode="json"),
                 status=status.HTTP_500_INTERNAL_SERVER_ERROR
             )

⛔ Skipped due to learnings

Learnt from: Achintya-Chatterjee
PR: Real-Dev-Squad/todo-backend#52
File: todo/views/task.py:98-112
Timestamp: 2025-06-02T17:02:22.424Z
Learning: The todo-backend project uses a global exception handler that automatically handles TaskNotFoundException, BsonInvalidId, ValueError with ApiErrorResponse, and DRFValidationError. Views should avoid try-catch blocks and let exceptions bubble up to the global handler for consistent error formatting and status codes.

Learnt from: Achintya-Chatterjee
PR: Real-Dev-Squad/todo-backend#52
File: todo/views/task.py:98-112
Timestamp: 2025-06-02T17:02:22.424Z
Learning: In the todo-backend project, there is a global exception handler in `todo/exceptions/exception_handler.py` that handles exceptions globally, eliminating the need for try-catch blocks in individual view methods. This approach reduces boilerplate code and provides consistent error handling across the application.

---

27-27: No action needed: request.user_id is set by JWTAuthenticationMiddleware

The JWTAuthenticationMiddleware in todo/middlewares/jwt_auth.py reliably assigns request.user_id for both Google (payload["user_id"]) and RDS (payload["userId"]) authentication flows, and it’s included in the MIDDLEWARE list in todo_project/settings/base.py. The original concern can be safely dismissed.

todo/tests/unit/views/test_auth.py (1)

1-249: Test updates look good!

The test changes appropriately reflect the updated authentication flow:

• Callback now uses GET and returns redirects with error parameters
• Refresh token endpoint tests removed to match implementation
• New tests for session and cookie clearing on logout

todo/views/auth.py (1)

200-236: Logout implementation looks good!

The logout flow properly:

• Flushes the session to clear all session data
• Returns a consistent JSON response
• Clears authentication and session cookies with proper domain/path settings